The disclosures herein relate generally to automated production environments and, more particularly, to a technique for performing very high speed software downloads concurrent with system testing in such an environment.
This application relates to U.S. Pat. No. 6,591,418, issued Jul. 8, 2003, entitled FACTORY SOFTWARE MANAGEMENT SYSTEM naming Joe Bryan, Steve Romohr, Jon Boede, Gaston M. Barajas and Paul J. Maia as inventors. This patent is incorporated herein by reference in its entirety, and is assigned to the assignee of this invention.
This application relates to U.S. Pat. No. 6,385,766, issued May 7, 2002, entitled METHOD AND APPARATUS FOR WINDOWS-BASED INSTALLATION FOR INSTALLING SOFTWARE ON BUILD-TO-ORDER COMPUTER SYSTEMS naming Bobby G. Doran, Jr., Bill Hyden and Terry Wayne Liles as inventors. This patent is incorporated herein by reference in its entirety, and is assigned to the assignee of this invention.
This application relates to U.S. Pat. No. 6,543,047, issued Apr. 1, 2003, entitled METHOD AND APPARATUS FOR TESTING CUSTOM-CONFIGURED SOFTWARE/HARDWARE INTEGRATION IN A COMPUTER BUILD-TO-ORDER MANUFACTURING PROCESS naming Thomas Vrhel, Jr., Gaston M. Barajas, Paul J. Maia and Todd Nix as inventors. This patent is incorporated herein by reference in its entirety, and is assigned to the assignee of this invention.
Historically, computer manufacturers have tested computer systems in production under DOS. There are several problems with this. First, because DOS is not a multi-tasking operating system, as the complexity of the computer systems being tested increases and more tests are required, the time required to perform those tests also increases, resulting in reduced manufacturing throughput. Second, DOS does not support testing of certain types of systems, such as Symmetrical Multi-Processor (“SMP”) systems and RAID controllers, which must be tested under a multi-tasking operating system. Finally, DOS will not execute under 64-bit processors shipped on certain computer systems; a multi-tasking operating system will be necessary to properly test such systems.
A process has been developed to solve the above-noted problems; namely, to provide support for components that could not be tested under DOS and to reduce test times through parallel testing. This process, referred to herein as “WinTest”, installs from DOS onto a target system, and then boots to a multi-tasking OS, such as Windows NT Server, Enterprise Edition (“NTSE”), available from Microsoft Corporation, Redmond, Wash., launches and runs Windows-based diagnostics, and then boots back to DOS. However, in running applications and tests under a multi-tasking environment, there are three fundamental problems, including (1) how to control the application or test, (2) how to determine pass/fail status for the application or test, and (3) how to communicate this status to the WinTest architecture.
In a DOS environment, the foregoing tasks are fairly simple. Most applications are controlled through command line parameters or configuration files; pass/fail status is typically returned through an ERRORLEVEL environment variable; and the only installation/removal involves adding/deleting files. Working under a multi-tasking environment, such as NTSE, however, is much more complicated. Each application is controlled differently, often through mouse/keyboard events, each application determines pass/fails status differently, often by opening/closing windows, changing window contents, and creating files, for example, and installing applications often requires manipulation of the registry, base files, and shared files and ActiveX Servers. Thus, there is no standard way to integrate applications/tests into the automated production environment.
An additional problem suffered in the DOS environment is that production-installed software is downloaded in the burnracks in a sequential manner. Accordingly, as the size of the software installs continues to grow, the download times also continue to increase, which reduces production speeds and increases cost-per-system. While network speed increases can help to alleviate this problem to some extent, at some point, the download becomes limited to the performance of the hard drive on the client system and download times increase linearly with download sizes. There is currently no means to reduce the impact of the software downloads once the client hard drive limit has been reached.
In the build-to-order environment, each system executes a unique set of process steps in production. In the DOS environment, this sequence is specified in a “step file” and the actual sequencing is controlled by an application referred to as “RunStep.” RunStep, however, only provides sequential step execution. Under WinTest, each production system has a multi-tasking OS, such as NTSE, installed in the burnracks and multiple diagnostics (over 20) are run in parallel. The ability to run these diagnostics in parallel significantly reduces total test time (by over ten hours in the case of servers), which provides a large competitive advantage. However, RunStep does not provide the ability to execute steps in parallel. Further, in the DOS environment, the step execution, status display, test log viewing, and Electromechanical Repair (“EMR”) debug tools are deployed as separate tools. This requires extensive EMR training, adds significant overhead to the EMR process, and makes it impossible to determine the location of the system in the overall test process while it is running.
Therefore, what is needed a system that enables software downloads to be performed in parallel with system testing and that provides a sequencing engine that enables the execution of “steps” in parallel under a multi-tasking OS, such as NTSE.